ECS の新しい Container Insights を使って CloudWatch だけで Observablity！Java アプリケーションをセットアップして、ログ、メトリクス、トレースの関連付けに加えて SLO 管理までやってみた！
2024.12.26先日 Container Insights with Enhanced Observability を ECS で利用できるようになりました。
ECS 用の Container Insights が新しくなったのですが、AWS 公式ブログに依ると下記のようなメリットがあるようです。
詳細なリソース使用パターンを確認し、テレメトリデータを関連付けることで、根本原因を迅速に特定できます。
AWS ベストプラクティスに基づいて厳選されたダッシュボードを使用して ECS リソースをプロアクティブに管理します。
最新のデプロイとデプロイ失敗の根本原因をトラッキングし、一致するインフラストラクチャの異常を特定することで、より迅速に問題を検出し、必要に応じて迅速なロールバックを行えます。
手動で設定しなくても、複数のアカウントのリソースを簡単に監視できます。組み込みのクロスアカウントサポートにより、一元的なオブザーバビリティを得て運用上のオーバーヘッドを削減できます。
Application Signals や CloudWatch Logs といった他の CloudWatch サービスと統合することで、インフラストラクチャと実行中のサービスを相互に関連付け、影響を受けるサービスを特定するシームレスな体験が得られます。
これだけだと分かりづらいので、 Java アプリケーションに CloudWatch エージェントをセットアップして、実際にダッシュボードを確認してみました。
セットアップ
Spring Boot を利用した、簡単な Web 3 層のアプリケーションをサンプルとして利用します。
ソースコードは下記リポジトリに上げていますので、ご興味があればご確認下さい。
Container Insights with Enhanced Observability でも ECS からパフォーマンスログを出力して可視化することで、より詳細な情報を得るという大原則は変わっておりません。
ただ、CloudWatch の他機能を有効化することでメトリクスと同じダッシュボードからそれらの情報を確認することが可能です。
今回は Container Insights の機能を最大限引き出すため、Application Signals や Application Insights など、連携できるものは軒並み有効化していきます。
Application Signals を利用するに辺り、アプリケーションコンテナ内に自動計装エージェントを追加しつつ、サイドカーとして CloudWatch エージェントを追加しております。
細かいセットアップ方法は省略するので、必要に応じて GitHub にあげているソースコードを見て下さい。
また、弊社佐藤智樹の下記記事が詳しいので是非参照いただければと思います。
Application Insights やライフサイクルイベントはダッシュボードからボタンをクリックすることで有効化しました。
ダッシュボードを見てみる
ダッシュボードはこんな感じです。
クラスター/インスタンス/サービス/タスクファミリー/タスク/コンテナとメトリクスをどの粒度で見るかに依ってビューが別れています。
また、各ビューの下部にリソースのパフォーマンスや Application Signals など追加領域があることも特徴的です。
ちなみに、タスクファミリーは同じタスク定義から作成されたタスクをまとめてグループにしたものなので、基本的にサービスと同じものになるようです。
AWS 公式ブログの中ではタスクファミリーを使ってフィルタリングしているので、こちらを使うのが良いのかなと思いました。
見れるメトリクスに変わりはありませんが、ビュー下部で見れる情報はタスクファミリーの方が細かいように思いました。
サービス
タスクファミリー
各ビューの下に存在する追加領域が AWS 公式ブログで言う所の各 CloudWatch サービスとのシームレスな関連付けにあたるようなので、タスクファミリーのビューで詳しく見てみます。
Application Signals や CloudWatch Logs といった他の CloudWatch サービスと統合することで、インフラストラクチャと実行中のサービスを相互に関連付け、影響を受けるサービスを特定するシームレスな体験が得られます。
ビューの下部には下記 4 つの領域が存在します。
- Application Signals
- Application Insights
- ライフサイクルイベント
- リソースのパフォーマンス
各機能を有効化していれば、ダッシュボードに統合された形で表示されます。
ここは興味深かったので、それぞれを詳しく見ていきます！
Application Signals
SLI/SLO の設定をしていれば、メトリクスと合わせて異常性を確認できます。
良い感じに異常になってますね。
クリックしてみると、Application Signals のページに飛びます。
ここで、Synthetics Canary は異常性を示してないことがわかります。
タブが赤くなっているので、サービスオペレーションに移動します。
どうやら /task パスが SLO を満たしていないようです。
「オペレーションでの SLO をすべて表示」から詳細情報に飛びます。
レイテテンシーが 6.64 秒ということで大分遅く、ここで違反していることがわかります。
また、可用性の情報からエラーレスポンスを返却していることもわかります。
Container Insights というより Application Signals のビューですが、かなり良いですよね。
単なるメトリクス情報ではなく、SLI/SLO を意識した形でメトリクスを見れています。
元のビューに戻ると「依存関係」が存在するのでそちらに移動します。
ここで PostgreSQL のクエリが極めて遅いことがわかります。
0 スケールする Aurora Serverless に久しぶりにクエリを投げていたりするのでまぁ当然遅いんですが、ここまでわかれば Performance Insights なり何なりで DB 側を見ようって判断できますね。
ちなみに、2024 年 11 月に Application Signals でランタイムメトリクスも見れるようになっていました！
ヒープ領域の情報や GC 関連の情報が見れています。
せっかくランタイムにエージェント(自動計装エージェント)入れてるんだから良い感じに見せてくれたらと思う所ですが、ちゃんと見れます。
CloudWatch めっちゃ進化してますね！！
リソースのパフォーマンス
リソースのパフォーマンス欄についても見ていきます。
各コンポーネントのメトリクス情報サマリが記載してありますが、ここから「アクション」をクリックすることで他のテレメトリ情報を見にいくことができます。
公式ブログで言う所のこの部分にあたる機能でしょうか。
詳細なリソース使用パターンを確認し、テレメトリデータを関連付けることで、根本原因を迅速に特定できます。
今回レイテンシが気になるワークロードなので、「AWS X-Ray トレースを表示」をクリックしてみます。
そうすると、下記ページに遷移しました。
X-Ray のサービスページに飛ばしてくれるから良い感じにクエリしろってことですね。
とはいえ、何秒以上かかったリクエストを洗い出すといった簡単な分析であれば、サンプルクエリから適用するだけで十分ですね。
クエリを実行すると SLO 違反の要因となったリクエストが出てきます。
こんな感じで見れます。Aurora Serverless が 0 スケールしてしまっていたので、そもそもコネクション貼れずにタイムアウトしてそう、といった内容を見ることができました。
「アプリケーションログを表示」といったアクションもあります。
こちらをクリックすると、CloudWatch Logs Insights に遷移します。
こちらも良い感じにクエリしてくれって感じですね。
ぶっちゃけメトリクス/ログ/トレースの関連付けみたいな話はまだまだユーザー側の技量に掛かっている感は否めないですが、この辺を関連付けてみれるようにしようという意思は感じますね。
ちなみに、Query generator に自然言語で投げたらクエリを作成してくれました。
CloudWatch に慣れていないとメトリクスとログの結びつけには時間がかかりそうですが、生成 AI がそのギャップを埋めてくれるというのはなかなか良いかもしれないと思いました。
運用業務にもバリバリ生成 AI 使っていきたいですよね。
Application Insights
Application Signals だけでなく、Application Insights も統合可能です。
こちらを統合することで、よりアクティブにサービス影響がありそうなパターンを検知可能です。
明示的にアラームを設定せずとも、こんな感じで検知してくれます。
今回は 5xx エラーが一時的に多かったという所でしたが、こちらを活用することでよりポイントを絞ってメトリクスを確認できますね！
Application Insights 自動セットアップと新しい Container Insights の相性?
Application Insights は新しい Container Insights のダッシュボードからボタンひとつで有効化できるのですが、そちらの設定を行うと Container Insights が古いものに戻るという現象に苦しめられました。
新しい Container Insights を最大限活用したくて機能を有効化したら、Container Insights の設定自体が巻き戻るということでしばらくハマりました。
Config や CloudTrail を見ればわかるのですが、Application Insights 自動セットアップを利用すると ApplicationInsightsOnboardingEngine というロール経由で、定期的に Container Insights の設定を上書きするようです。
API コールを一部抜粋します。
"eventSource": "ecs.amazonaws.com",
"eventName": "UpdateClusterSettings",
"awsRegion": "ap-northeast-1",
"sourceIPAddress": "application-insights.amazonaws.com",
"userAgent": "application-insights.amazonaws.com",
"requestParameters": {
"settings": [
{
"name": "containerInsights",
"value": "enabled"
}
],
"cluster": "SpringBootFargateStack-ClusterEB0386A7-7c82lo1BYNWw"
},
※ 新しい Container Insights を利用する場合、requestParameters で下記のように enhanced を指定する必要があります。
"requestParameters": {
"settings": [
{
"name": "containerInsights",
"value": "enhanced"
}
],
"cluster": "SpringBootFargateStack-ClusterEB0386A7-7c82lo1BYNWw"
},
最初は Container Insights のアカウント設定が問題かと思いましたが、この辺りを触っても変わらなかったので諦めました。
細かく設定すれば良い感じになるかもしれないですが、いずれ解消するように思ったので放っておこうと思います(良い設定を知っていたら是非教えていただきたいです)。
イベントライフサイクル
ECS 側のイベント(タスク起動、停止など)をメトリクスと同じダッシュボードから確認できるようになっています。
デプロイなどのイベントとメトリクス情報は是非関連付けてみたいので、嬉しい機能ですね。
各コンテナのリミットを設定しないと CPU/メモリが確認できない話
元々 Container Insights には CPU やメモリのリミット値を設定しないと、コンテナごとの CPU 利用率/メモリ利用率が閲覧できないという仕様がありました。
この点は新しくなった Container Insights でも変わらないようです。
下記画像において、リビジョン 6 がリミット指定なし、リビジョン 7 がリミット指定ありのタスクになります。
リミット指定ありのタスクのみで、コンテナ毎の CPU 使用率/メモリ使用率が見れてますね。
タスク内に複数コンテナが存在するワークロードでは、この辺りの設定を忘れずに行うと良いかと思います。
まとめ
アップデートの内容としては Container Insights の UI が新しくなったという話ではあるのですが、Application Signal や Application Insights の進化も合わせて、CloudWatch だけで Observability やっていくぞ！という気持ちを感じる内容でした。
これからの進化にも期待ですね！
![[re:Growth 2024 福岡]「DevOps視点でAWS re:invent2024の新サービス・アプデを振り返ってみた」というタイトルで登壇しました！ #regrowth_fuk](https://images.ctfassets.net/ct0aopd36mqt/5ryxrWm66BrRgrQX4iE2ff/9312299ce7ed3de7fec707d91261aa4c/241212_regrowthfukuoka_w1200h630.png)
